Evaluating the effectiveness of a threat model

ABSTRACT

Evaluating a threat model for structural validity and descriptive completeness. A threat modeling application provides a progress factor or other overall score associated with the structural validity and descriptive completeness of the threat model being evaluated. The structural validity is evaluated based on a data flow diagram associated with the threat model. The descriptive completeness is evaluated by reviewing descriptions of threat types in the threat model. The progress factor encourages modelers to provide effective models to a model reviewer, thus saving time for the model reviewer.

BACKGROUND

A threat model is a conception tool for identifying security risks insoftware and other information systems. Threat modeling often includesan analysis of a data flow diagram. Data flow diagrams describe themovement of information in an information system such as a softwaresystem, the sources of information, what processes occur on theinformation, where the information is stored, and where the informationeventually flows. The effectiveness of a threat model is dependent upon,for example, the structural validity and completeness of the threatmodel. Existing systems fail to evaluate the effectiveness of the threatmodel prior to threat model being reviewed by a model reviewer such as asecurity expert.

SUMMARY

Embodiments of the invention evaluate a threat model for effectiveness.Portions of a data flow diagram associated with the threat model arereceived. The threat model has one or more threat types corresponding toeach of the elements in the data flow diagram. Connections between theelements are evaluated as the portions are received to generate avalidity factor for each of the threat types. The generated validityfactor is provided to a user for analysis of the threat model. In someembodiments, a description of each of the threat types for each of theelements is evaluated to generate a completeness factor for the threattype. The validity factor and the completeness factor are provided tothe user as a progress factor for the threat model.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary block diagram illustrating an operatingenvironment suitable for use in implementing embodiments of theinvention.

FIG. 2 is an exemplary block diagram of a computing device having amemory area storing components for evaluating threat models.

FIG. 3 is an exemplary user interface illustrating a threat modelingapplication.

FIG. 4 is an exemplary flow chart illustrating an evaluation of a threatmodel.

FIG. 5 is an exemplary user interface illustrating a threat modelingapplication applying structural validation to a threat model.

FIG. 6 is an exemplary user interface illustrating a generated threatmodel listing completion status of possible threats before anevaluation.

FIG. 7 is an exemplary flow chart illustrating a decision making processin determining a completion status of possible threats.

FIG. 8 is an exemplary user interface illustrating a generated threatmodel listing completion status of possible threats after an evaluation.

FIG. 9 is an exemplary user interface illustrating a generated analysisreport of an evaluation of a threat model.

FIG. 10 is an exemplary user interface illustrating a data flow diagram.

FIG. 11 is an exemplary user interface illustrating a three dimensionalgraph report of a data flow.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION

Referring to the figures, embodiments of the invention enable theanalysis of a threat model 112. In some embodiments, a threat modelingapplication 108 executes on a computing device operated by a user orother entity and analyzes a data flow diagram 110 and the threat model112 stored in a data store associated with the computing device. Thedata flow diagram 110 includes a plurality of elements 118 arranged todescribe a flow of data through an information system (see FIG. 5).Exemplary elements in the data flow diagram 110 such as “IDeviceStatus”and “Application” are illustrated in FIG. 5.

In other embodiments, the user (e.g., at a second computing device 106)sends portions of the data flow diagram 110 and a corresponding threatmodel such as threat model 112 to a first computing device 102 via anetwork 104. The first computing device 102 includes the threat modelingapplication 108 that provides an analysis of the threat model 112 beingevaluated. The evaluation of the threat model 112 is based on, forexample, structural validity and descriptive completeness. Inembodiments, the threat modeling application 108 provides structuralfeedback, completeness feedback, and an overall score or progressindicator regarding the threat model 112. Exemplary scores regarding atype of error encountered for a particular threat are illustrated inAppendix A. In embodiments, the structural feedback identifiesstructural defects of the threat model 112 in real-time or nearreal-time (e.g., as the data flow diagram 110 is being created or read).The completeness feedback identifies elements (e.g., elements 118 of thethreat model 112) that, for example, do not have possible threats, havethreats that are not described, have unmitigated threats, or havethreats not associated with an issue tracking identifier (e.g., bugnumber).

While aspects of the invention are described with reference to threatmodeling for application programs, aspects of the invention are operablegenerally with information systems including software systems having oneor more application programs, processes, and/or data stores. Further,while the user provides the data flow diagram 110 and the threat model112 in some embodiments, other embodiments contemplate the threatmodeling application 108 accessing either or both of the data flowdiagram 100 and the threat model 112 independent of the user.

Referring next to FIG. 2, an exemplary block diagram shows a computingdevice 202 having at least one processor 204, a display 206, and amemory area 208. In an embodiment, the processor 204 is transformed intoa special purpose microprocessor by executing computer-executableinstructions or by otherwise being programmed. For example, theprocessor 204 is programmed with instructions such as illustrated inFIG. 3 to evaluate the threat model 112. The diagram of FIG. 2 is merelyillustrative of an exemplary computing device that may be used inconnection with one or more embodiments of the invention, and is notintended to be limiting in any way.

With continued reference to FIG. 2, memory area 208, or othercomputer-readable media, stores computer-executable components forevaluating threat models, for example, the threat model 112. Exemplarycomponents within the memory area 208 include, but are not limited to aninterface component 210, a model component 212, a structural component214, and a report component 216.

The interface component 210 accesses the data flow diagram 110 for aninformation system. In some embodiments, the interface component 210displays the accessed data flow diagram 110 to a user as atwo-dimensional model (see FIG. 5) or as a rotatable three-dimensionalmodel (see FIG. 11). The interface component 210 further accesses thethreat model 112 corresponding to the data flow diagram 110. The threatmodel 112 has one or more threat types corresponding to each of theplurality of the elements 118. The interface component 210 receives arequest from the user for a determined progress factor and provides tothe user, responsive to the received request from the user, a determinedprogress factor for each of the threat types. In other embodiments, theprogress factor is determined and provided automatically in a userinterface or report.

In embodiments, the model component 212 evaluates a description in thethreat model 112 of each of the threat types for each of thecorresponding elements 118 to generate a completeness factor for thethreat type. Exemplary descriptions of threat types may be found in FIG.6. The model component 212 identifies empty threats or undescribedthreats that are associated with one of the element 118 and have athreat type without any details. The model component 212 also identifiesunmitigated threats that are associated with one of the elements 118 andhave a threat type but no description of how the software systemresponds to the threat or mitigates the threat. This may occur, forexample, if the user has not completed filling out the description inthe threat model 112.

The structural component 214 evaluates connections between the elements118 in the data flow diagram 110 accessed by the interface component 210to generate a validity factor for each of the threat types. Inembodiments, evaluating the connections between each of the elements 118includes evaluating logical connections between the elements 118 andevaluating spatial connections between the elements 118. For example, asshown In FIG. 5, “DeviceStatus” is connected to element “Application”but is not connected to element “IDeviceStatus.” Therefore, thisdisconnect will affect the validity factor for that particular threat.

In some embodiments, logical evaluation includes the examination of onlythe abstract layout, or graph, of the data flow diagram 110 in thethreat model 112. In such an embodiment, the threat modeling application108 iterates through a list of the elements 118 in the data flow diagram110 and compares adjacent elements. In some cases, the threat modelingapplication 108 follows chains of connected elements 118 untilparticular types of elements 118 are found or not found. In contrast,spatial evaluation examines the two-dimensional layout of the threatmodel 112 for errors, such as the spatial relationships of trustboundaries (see FIG. 10).

Referring back to FIG. 2, the report component 216 determines theprogress factor for each of the threat types based on the completenessfactor generated by the model component 212 and the validity factorgenerated by the structural component 214. The interface component 210provides the progress factor determined by the report component 216 foreach of the threat types to the user as an indication of theeffectiveness of the threat model 112. In embodiments, the reportcomponent 216 assigns a first weight to the completeness factor based onthe evaluated description, assigns a second weight to the validityfactor based on the evaluated connections, and combines the completenessfactor and the validity factor based on the first weight and the secondweight to determine the progress factor. The assignment of the first andsecond weights is configurable by, for example, the user or modelreviewer, and no particular ordering of the weights is implied by theterms “first” and “second.”

Referring next to FIG. 3, portions of the data flow diagram 110 for aninformation system are received at 302. In some embodiments, theportions of the data flow diagram 110 are received from the user via auser interface. In further embodiments, the portions of the data flowdiagram 110 are received from an extensible markup language (XML) filecorresponding to the data flow diagram 110.

At 304, the threat model 112 corresponding to the received portions ofthe data flow diagram 110 is accessed. While the embodiment of FIG. 3illustrates the validity factor being determined as a function of boththe data flow diagram 110 and the threat model 112, other embodimentsinclude the validity factor being determined as a function of either thedata flow diagram 110 (e.g., structural validity) or the threat model112 (e.g., descriptive completeness), but not both.

At 306, connections between the elements 118 in the portions of the dataflow diagram 110 are evaluated as the portions are received to generatea validity factor for each of the threat types. In embodiments, theconnections are evaluated in real-time as the portions are received bythe threat modeling application 108 in the first computing device 102.The evaluation identifies structural defects. For example, the portionsare sent from the second computing device 106 to the first computingdevice 102 as the user creates the data flow diagram 110. In furtherembodiments, evaluating the connections includes one or more of thefollowing: identifying intersections between the connections,identifying one or more of the elements 118 lacking a connection toanother of the elements 118, identifying a data store element lacking aconnection to a process element via a data flow element, and identifyinga trust boundary element lacking a data flow element crossing over thetrust boundary element.

At 308, a generated validity factor is provided to the user for analysisof the threat model 112. In embodiments, providing the generatedvalidity factor includes providing an incremental progress bar (e.g., acompletion progress bar as shown in FIG. 8) for display to the user. Infurther embodiments, the incremental progress bar corresponds to thegenerated validity factor and/or completeness factor.

Referring next to FIG. 4, an exemplary flow chart illustrates theactions performed in evaluating the threat model 112. At 402, a requestfrom the user to store the data flow diagram 110 and the correspondingthreat model 112 in the memory area 208 is received at the firstcomputing device 102. At 404, the received data flow diagram 110 isevaluated for structural validity. At 406, the corresponding threatmodel 112 is evaluated for descriptive completeness. At 408, a progressvalue for the received data flow diagram 110 and the correspondingthreat model 112 is generated based on the evaluation of the receiveddata flow diagram 110 and the corresponding threat model 112. At 410,the generated progress value is compared to a predefined thresholdvalue. In embodiments, the predefined threshold value corresponds to aminimum level of effectiveness of the corresponding threat model 112. At412, a determination is made as to whether the generated progress valueis greater than or equal to the predefined threshold value. If it isdetermined that the generated progress value is greater than or equal tothe predefined threshold value, at 414, the received data flow diagram110 and the corresponding threat model 112 are stored in the memory area208. However, if it is determined that the generated progress value isless than the predefined threshold value, at 416, the received data flowdiagram 110 and the corresponding threat model 112 are rejected. Inembodiments, the user is notified of the rejection of the received dataflow diagram 110 and the corresponding threat model 112.

In some embodiments, FIG. 4 represents an online validation system, webservice, or plug-in that evaluates threat models 112. For example, ifthe threat model 112 meets a particular format (e.g., XML format), avalidation engine evaluates and scores the threat model 112.

Referring next to FIG. 5, an exemplary user interface 502 illustrates anexemplary threat modeling application (e.g., threat modeling application108) or other threat modeling tool applying structural validation to anexample of the threat model 112. In the exemplary threat modelillustrated in the user interface 502, a square shape “IDeviceStatus,”an external interactor element, is isolated from the rest of thediagram, and the curved arrow “DeviceStatus” is not connected at bothends. Therefore, on the left side of the user interface 502, under“DiagramValidation,” the threat modeling application 108 identifies twoproblems upon applying a structural validation and informs the user ofthe identified problems.

Referring next to FIG. 6, an exemplary user interface 602 illustrates agenerated threat model 112 and a completion status of possible threatsidentified by the threat modeling application 108. The threat model 112in the user interface 602 lists the element names, corresponding elementtypes, and threat types. The completion status is indicated by theprogress bar. In the example of FIG. 6, the progress bar is illustratedas a series of segmented rectangles. The progress bar may becolor-coded, textured, or crosshatched based on a value associated withthe progress factor (e.g., a level of completeness and structuralvalidity). Each segmented rectangle or each progress bar under the“completion” column may be color-coded based on the type of descriptionof the possible threat. In some embodiments, the progress bar isillustrated as a gradient of color from left-to-right in FIG. 6. Forexample, progress bars showing mostly red indicate a mostly incompletedescription and/or structural validity for the threat. Similarly,progress bars showing mostly green indicate a mostly completedescription and/or structural validity for the threat. In someembodiments, each segment in the rectangles corresponds to a particularmilestone or decision component involved in determining the progressfactor. Exemplary milestones and decision components are next describedwith reference to FIG. 7.

Referring next to FIG. 7, an exemplary flow chart 702 illustrates adecision making process in determining the completion status of possiblethreats. Following the flow chart 702, the questions asked regarding thedescription of a threat determine the length of a completion progressbar. For example, if a threat is described, a completion progress baradvances 25%. The incrementing of, for example, 25% as shown in the flowchart 702 is exemplary and other increments of increasing the completionprogress bar are within the scope of embodiments of the invention.

The exemplary flow chart 702 illustrates certifications. Certificationscorrespond to elements 118 and threat types for which the user or othermodeler has certified that there are no threats of a given type at all.The flow chart 702 also illustrates a decision box for omittingevaluation of informational elements, or elements 118 included in thethreat mode for context reasons but not threat-related reasons.

Referring next to FIG. 8, an exemplary user interface 802 illustrates agenerated threat model 112 including the completion status of possiblethreats identified by the threat modeling application 108 after anevaluation of the possible threats. For example, user interface 802illustrates the results of each threat being processed through adecision tree such as shown in flow chart 702. The progress bars shownin the user interface 802 illustrate a level of completion of each ofthe listed threats by associating the completion of a threat with alength of the completion progress bar. For example, a fully describedthreat has all four boxes under the “completion” column filled.

Referring next to FIG. 9, is an exemplary user interface 902illustrating a generated analysis report of an evaluation of the threatmodel 112. As shown in the user interface 902, the analysis reportincludes, but is not limited to, a list of elements that are identifiedas including an error and the type of error associated with theparticular element. For example, the section labeled “Empty Threats”identifies elements that contain no threat description. The data flowdiagram corresponding to the threat model 112 for FIG. 9 has avalidation score of −1200 based on the exemplary scores provided inAppendix A. That is, the validation score is computed as the sum of thescores for the DataFlowTooFewConnections error (−1000) and theInteractorIsolated error (−200).

In some embodiments (not shown), the user interface 902 displays fuzzingtargets identified, selected, and recommended by the threat modelingapplication 108. The fuzzing targets represent opportunities to fuzz, orautomatically generate random input for testing, in the software systemcorresponding to the data flow diagram 110.

Referring next to FIG. 10, an exemplary user interface 1002 illustratesan exemplary data flow diagram. The exemplary user interface 1002 isassociated, for example, with the threat modeling application 108 orother threat modeling tool. The exemplary data flow diagram in the userinterface 1002 corresponds to a compressor-decompressor (CODEC). Adotted line in the lower right-hand corner represents a trust boundary.The trust boundary is clearly not located spatially close enough to, orintersecting with, any element 118 to imply an association. As such,when evaluating the structural completeness of this exemplary data flowdiagram 110, the threat modeling application 108 identifies this trustboundary as an error.

Appendix B includes an exemplary threat model report detailing thedescriptive completeness of the data flow diagram 110, but omitting theprogress bars.

Referring next to FIG. 11, an exemplary user interface 1102 illustratesa three-dimensional model of a data flow diagram. That is, the interfacecomponent 210 displays an accessed data flow diagram to the user as arotatable three-dimensional model.

Exemplary Operating Environment

A computer or computing device such as described herein has one or moreprocessors or processing units, system memory, and some form of computerreadable media. By way of example and not limitation, computer readablemedia comprise computer storage media and communication media. Computerstorage media include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Communication media typically embodycomputer readable instructions, data structures, program modules, orother data in a modulated data signal such as a carrier wave or othertransport mechanism and include any information delivery media.Combinations of any of the above are also included within the scope ofcomputer readable media.

The computer may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer.Although described in connection with an exemplary computing systemenvironment, embodiments of the invention are operational with numerousother general purpose or special purpose computing system environmentsor configurations. The computing system environment is not intended tosuggest any limitation as to the scope of use or functionality of anyaspect of the invention. Moreover, the computing system environmentshould not be interpreted as having any dependency or requirementrelating to any one or combination of components illustrated in theexemplary operating environment. Examples of well known computingsystems, environments, and/or configurations that may be suitable foruse with aspects of the invention include, but are not limited to,personal computers, server computers, hand-held or laptop devices,multiprocessor systems, microprocessor-based systems, set top boxes,programmable consumer electronics, mobile telephones, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

Embodiments of the invention may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. The computer-executableinstructions may be organized into one or more computer-executablecomponents or modules. Generally, program modules include, but are notlimited to, routines, programs, objects, components, and data structuresthat perform particular tasks or implement particular abstract datatypes. Aspects of the invention may be implemented with any number andorganization of such components or modules. For example, aspects of theinvention are not limited to the specific computer-executableinstructions or the specific components or modules illustrated in thefigures and described herein. Other embodiments of the invention mayinclude different computer-executable instructions or components havingmore or less functionality than illustrated and described herein.Aspects of the invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

The embodiments illustrated and described herein as well as embodimentsnot specifically described herein but within the scope of aspects of theinvention constitute exemplary means for determining the descriptivecompleteness and structural validity of the received data flow diagram110 and the corresponding threat model 112, and exemplary means forgenerating a value indicating an evaluation of the threat model 112.

The order of execution or performance of the operations in embodimentsof the invention illustrated and described herein is not essential,unless otherwise specified. That is, the operations may be performed inany order, unless otherwise specified, and embodiments of the inventionmay include additional or fewer operations than those disclosed herein.For example, it is contemplated that executing or performing aparticular operation before, contemporaneously with, or after anotheroperation is within the scope of aspects of the invention.

When introducing elements of aspects of the invention or the embodimentsthereof, the articles “a,” “an,” “the,” and “said” are intended to meanthat there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements.

Having described aspects of the invention in detail, it will be apparentthat modifications and variations are possible without departing fromthe scope of aspects of the invention as defined in the appended claims.As various changes could be made in the above constructions, products,and methods without departing from the scope of aspects of theinvention, it is intended that all matter contained in the abovedescription and shown in the accompanying drawings shall be interpretedas illustrative and not in a limiting sense.

APPENDIX A

Table A1 below lists some sample structural validations evaluated by thethreat modeling application 108.

TABLE A1 Exemplary Structural Validations. Structural ValidationExplanation DataFlowIsolated A data flow element is not connected to anyelement. DataFlowTooFewConnections A data flow element is not connect atboth ends. InteractorIsolated An external interactor element is notconnected to any element. InteractorTooFewConnections An externalinteractor has only one connection. ProcessIsolated A process is notconnected to any element. ProcessTooFewConnections A process has onlyone connection. MultiProcessIsolated A multiprocess element is notconnected to any element. MultiProcessTooFewConnections A multiprocesshas only one connection. DataStoreIsolated A data store element is notconnected to any element. DataStoreTooFewConnections A data store hasonly one connection. DataStoreConnectedToNonProcess A data store must beconnected only to a dataflow element that connects to a process. This isnot the case. DataStoreWithNoInputs A data store must receive data fromsomewhere, or the model is incomplete. The data store does not receivedata as it has no inbound data flows. DataStoreWithNoOutputs A datastore must emit data to somewhere, or the model is incomplete. (There isno point emitting data that will never be consumed.) This data store isnot connected to an outbound data flow.DataStoreNotConnectedToInteractor A data store is not connected, throughany number of inbound data flows and intermediate elements, with anexternal interactor. This would mean that the data has no source, so themodel is (very likely) incomplete. DataStoreNotConnectedFromInteractor Adata store is not connected, through any number of outbound data flowsand intermediate elments, with an external interactor. This would meanthat the data has no eventual use outside of the system, so the model is(very likely) incomplete. TrustBoundaryIsolated A trust boundary has nodata flows crossing over it. It is either superfluous or misplaced.TrustBoundaryNone There are no trust boundaries, so the model is (verylikely) not broad enough to be useful. NoNonInformationalProcess Thereare no processes or multiprocesses which are not marked as“informational” (present for context but not explicitly modeled). As athreat model reflects the flow and processing of data, it is (verylikely) incomplete.

An exemplary list of scores per type of problem determined in a threatmodel evaluation is shown below in Table A2. The structural validationscorrespond to those in Table A1 above.

TABLE A2 Exemplary Scores for Structural Validations. Score StructuralValidation −200 DataFlowIsolated −1000 DataFlowTooFewConnections −200InteractorIsolated −1000 InteractorTooFewConnections −200ProcessIsolated −1000 ProcessTooFewConnections −200 MultiProcessIsolated−1000 MultiProcessTooFewConnections −200 DataStoreIsolated −1000DataStoreTooFewConnections −200 DataStoreConnectedToNonProcess −200DataStoreWithNoInputs −200 DataStoreWithNoOutputs −200DataStoreNotConnectedToInteractor −200DataStoreNotConnectedFromInteractor −200 TrustBoundaryIsolated −10000TrustBoundaryNone −10000 NoNonInformationalProcess −1000000 Unknown

APPENDIX B

Listed below are portions of an exemplary threat model reportcorresponding to the data flow diagram illustrated in FIG. 10.

CODEC

Threats:

Tampering

-   -   Threat #16: When we pass the stream pointer to the metadata        handler, the metadata handler could do bad things.    -   Mitigation #16: Where possible, we pass a substream rather than        the full stream. A malicious metadata handler could access any        part of the stream, but some metadata handlers require access to        the entire stream because there could be references within the        metadata block to metadata elsewhere in the file. This is an        acceptable risk.

Information Disclosure

-   -   Threat #18: Writing an image file, the codec could write out an        uninitialized buffer, and could put information into a file that        shouldn't be there.    -   Mitigation #18: Infrastructure allocates its own memory and        zeros it out before using it.

Information Disclosure

-   -   Threat #3: In case an image is protected (or in a protected        container) the image data could be left in memory and        potentially accessible to another application if we don't zero        out the memory after usage.    -   Mitigation #3: Zero out memory after usage.

Elevation of Privilege

-   -   Threat #20: A bug in a codec could allow a buffer overrun that        could lead to arbitrary code execution.    -   Mitigation #20: We ensure strict compliance with image format        specifications. We also do annotations.

What is claimed is:
 1. One or more computer storage devices storingcomputer-executable components for evaluating a threat model for aninformation system, said components comprising: an interface componentthat when executed causes at least one processor to access a data flowdiagram for an information system, said data flow diagram comprising aplurality of elements arranged to describe a flow of data through theinformation system, said interface component further accessing a threatmodel corresponding to the data flow diagram, said threat model havingone or more threat types corresponding to each of said plurality ofelements; a model component that when executed causes at least oneprocessor to evaluate a description in the threat model of each of thethreat types for each of the corresponding elements to generate acompleteness factor for the threat type, wherein the model componentevaluates the description in the threat model at least by identifyingone or more of the following associated with one of the elements andhaving a threat type: empty threats, undescribed threats, andunmitigated threats; a structural component that when executed causes atleast one processor to evaluate connections between the elements in thedata flow diagram accessed by the interface component to generate avalidity factor for each of the threat types; and a report componentthat when executed causes at least one processor to determine a progressfactor for each of the threat types based on the completeness factorgenerated by the model component and the validity factor generated bythe structural component, wherein the interface component provides theprogress factor determined by the report component for each of thethreat types to a user as an indication of effectiveness of the threatmodel.
 2. The computer storage devices of claim 1, wherein evaluatingthe connections between each of the elements comprises evaluatinglogical connections between the elements by iterating through theelements in the data flow diagram and comparing adjacent elements. 3.The computer storage devices of claim 1, wherein evaluating theconnections between each of the elements comprises evaluating spatialconnections between the elements by examining a two-dimensional layoutof the threat model for errors.
 4. The computer storage devices of claim1, wherein the report component further: assigns a first weight to thecompleteness factor based on the evaluated description; assigns a secondweight to the validity factor based on the evaluated connections; andcombines the completeness factor and the validity factor based on thefirst weight and the second weight to determine the progress factor. 5.The computer storage devices of claim 1, wherein the interface componentfurther displays the accessed data flow diagram to the user as arotatable three-dimensional model.
 6. The computer storage devices ofclaim 1, wherein the interface component further receives a request fromthe user for the determined progress factor and provides, responsive tothe received request from the user, the determined progress factor foreach of the threat types to the user.
 7. A method comprising: receivingportions of a data flow diagram for an information system, said portionsof the data flow diagram comprising a plurality of elements arranged todescribe a flow of data through the information system; accessing athreat model corresponding to the data flow diagram, said threat modelhaving one or more threat types corresponding to each of the elements;generating a completeness factor for each of the one or more threattypes by evaluating a description in the accessed threat model of eachof the one or more threat types for each of the corresponding elements,wherein evaluating the description includes at least identifying one ormore of the following associated with one of the elements and having athreat type: empty threats, undescribed threats, and unmitigatedthreats; evaluating, by one or more processors, connections between theelements in the portions of the data flow diagram as the portions arereceived to generate a validity factor for each of the one or morethreat types, wherein evaluating includes identifying structural defectsin the data flow diagram; and providing the generated completenessfactor and the generated validity factor for analysis of the threatmodel.
 8. The method of claim 7, wherein receiving the portions of thedata flow diagram comprises receiving the portions of the data flowdiagram from a user via a user interface.
 9. The method of claim 7,wherein receiving the portions of the data flow diagram comprisesreceiving the portions of the data flow diagram from an extensiblemarkup language (XML) file corresponding to the data flow diagram. 10.The method of claim 7, wherein evaluating the connections comprisesevaluating the connections in real-time as the portions are received,the method further identifying undescribed threats associated with theone or more elements.
 11. The method of claim 7, wherein the validityfactor is affected by disconnection between at least two elements in thedata flow diagram.
 12. The method of claim 7, wherein providing thegenerated validity factor comprises providing an incremental progressbar for display to a user, said incremental progress bar correspondingto the generated validity factor.
 13. The method of claim 7, whereinevaluating the connections comprises identifying intersections betweenthe connections.
 14. The method of claim 7, wherein evaluating theconnections comprises one or more of the following: identifying one ormore of the elements lacking a connection to another of the elements,identifying a data store element lacking a connection to a processelement via a data flow element, and identifying a trust boundaryelement lacking a data flow element crossing over the trust boundaryelement.
 15. The method of claim 7, wherein evaluating the connectionsbetween the elements comprises evaluating spatial connections betweenthe elements by examining a two-dimensional layout of the threat modelfor errors.
 16. A system comprising: a memory area for storing a dataflow diagram for an information system, said data flow diagramcomprising a plurality of elements arranged to describe a flow of datathrough the information system, said memory area further storing athreat model corresponding to the data flow diagram, said threat modelhaving one or more threat types corresponding to each of said pluralityof elements; and a processor programmed to: generate a completenessfactor for each of the one or more threat types by evaluating adescription in the threat model of each of the one or more threat typesfor each of the corresponding elements, wherein evaluating thedescription includes at least identifying one or more of the followingassociated with one of the elements and having a threat type: emptythreats, undescribed threats, and unmitigated threats; generate avalidity factor for each of the one or more threat types by evaluatingconnections between the elements in the received data flow diagram;determine a progress factor for each of the one or more threat typesbased on the generated completeness factor and the validity factor; andprovide the determined progress factor for each of the threat types to auser as an indication of effectiveness of the threat model.
 17. Thesystem of claim 16, wherein the memory area and the processor areassociated with a first computing device, wherein the user is associatedwith a second computing device, and wherein the first computing deviceand the second computing device communicate via a network.
 18. Thesystem of claim 16, wherein the processor is further programmed to storethe data flow diagram and the corresponding threat model in the memoryarea based on a comparison of the determined progress factor and apredefined threshold value.
 19. The system of claim 16, wherein theprocessor is further programmed to reject, based on a comparison of thedetermined progress factor and a predefined threshold value, a requestfrom the user to store the data flow diagram and the correspondingthreat model in the memory area.
 20. The system of claim 16, whereinevaluating the connections between the elements in the received dataflow diagram comprises evaluating spatial connections between theelements by examining a two-dimensional layout of the threat model forerrors.